• feat: add Stainless SDK config and misc cleanups #132
• feat: rename Error to GridError and add additionalProperties to error schemas #131 👈 (View in Graphite)
• feat: add Customer API discriminators and consolidate customer changes #130
• feat: add Quote/Transaction discriminators and remove inline examples #129
• feat: add isPlatformAccount to PaymentInstructions and remove PaymentAccountOrWalletInfo refs #128
• feat: rename accounts to data in list external accounts response #127
• feat: convert single-value enums to const for base types #126
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Greptile Overview

Greptile Summary

Introduced a new GridError schema to standardize error responses and improve flexibility across the API. The changes add additionalProperties: true to all error schema details objects, allowing for extensible error metadata.

Key Changes:

• Created GridError schema with code, message, and flexible details object
• Refactored BulkCustomerImportErrorEntry to extend GridError using allOf composition instead of nested error structure
• Updated webhook response schemas (IncomingPaymentWebhookForbiddenResponse, IncomingPaymentWebhookUnprocessableResponse) to reference GridError instead of the old Error schema
• Added additionalProperties: true to details field in all HTTP error schemas (400, 401, 403, 404, 409, 412, 424, 500, 501)

Impact:
This change improves API flexibility by allowing error responses to include arbitrary additional details without breaking the schema contract. The refactoring of BulkCustomerImportErrorEntry improves reusability and maintainability by using composition with the base GridError schema.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The changes are purely additive to the OpenAPI schema and improve error handling flexibility. The new GridError schema maintains backward compatibility by preserving the same structure as the old Error schema while adding additionalProperties: true to details objects. The refactoring of BulkCustomerImportErrorEntry improves maintainability without changing the effective schema contract. All changes are mechanical schema updates with no logic changes.
• No files require special attention

sequenceDiagram
    participant Client
    participant API as Grid API
    participant Schema as Error Schema

    Note over Client,Schema: Error Response Flow

    Client->>API: API Request (invalid input)
    API->>Schema: Validate against Error400 schema
    Schema->>Schema: code, message, status (required)
    Schema->>Schema: details (additionalProperties: true)
    API->>Client: Return Error400 response

    Note over Client,Schema: Bulk Import Error Flow

    Client->>API: POST /bulk-import
    API->>API: Process import entries
    API->>Schema: Create BulkCustomerImportErrorEntry
    Schema->>Schema: Extend GridError (code, message, details)
    Schema->>Schema: Add correlationId (required)
    API->>Client: Return errors array with BulkCustomerImportErrorEntry[]

    Note over Client,Schema: Webhook Error Flow

    Client->>API: Webhook callback
    API->>Schema: Validate and prepare webhook response
    Schema->>Schema: Use GridError base schema
    Schema->>Schema: Add webhook-specific fields (reason, requiredFields)
    API->>Client: Return IncomingPaymentWebhook*Response